The cooldown configuration option does not exist in Dependabot's configuration schema. As of January 2025, Dependabot does not support a cooldown feature for delaying updates after dependency releases. The valid configuration options for controlling update frequency are schedule.interval (with values like daily, weekly, monthly) and open-pull-requests-limit. Consider removing this unsupported configuration or using alternative approaches like schedule.interval: weekly to achieve a similar effect of less frequent updates.

The workflow trigger has been changed from "pull_request_target" (in the removed Auto-Release.yml) to "pull_request". This is a significant change in behavior: "pull_request_target" runs in the context of the base repository and has write permissions to secrets and can modify the repository, while "pull_request" runs in the context of the PR's head branch. For a Release workflow that requires "contents: write" and "pull-requests: write" permissions, this change means the workflow will not have these permissions when triggered from forks. Verify this is intentional and that the Auto-Release action can work correctly with this trigger type, especially for PRs from forks.

The workflow trigger changed from "pull_request_target" (in the deleted Auto-Release.yml) to "pull_request" (in the new Release.yml). This is a significant change:

• "pull_request_target" runs in the context of the base branch with write permissions, making it suitable for releases that need to create tags and publish
• "pull_request" runs in the context of the PR branch with limited permissions

While the new workflow has "contents: write" and "pull-requests: write" permissions declared, these may not be sufficient when triggered by "pull_request" from fork PRs. Additionally, the workflow includes triggers like "opened", "reopened", and "synchronize" which will run on every PR update, potentially creating unwanted releases. Consider whether "pull_request_target" was intentionally changed, and if the workflow logic in PSModule/Auto-Release handles this correctly.

The workflow trigger has been changed from 'pull_request_target' to 'pull_request'. This is a significant security change. The 'pull_request_target' event runs in the context of the base repository and has access to repository secrets, which is important for creating releases. The 'pull_request' event runs in the context of the fork for external PRs and may not have the necessary permissions to create releases. Verify that this change is intentional and that the release action can still function correctly, especially for PRs from forks.